Re: IFS hole?
Rik Harris (rik@vifp.monash.edu.au)
Thu, 16 Dec 1993 12:07:44 +1100
Content-Length: 1894
X-Lines: 38
Status: O
Andrew Beckett <abeckett@fmlrnd.co.uk> wrote:
> In article <199312141810.LAA04881@nostromo.c3.lanl.gov> Mike Neuman write:
> |>
> |> I'm in the midst of securing a setuid executable that allows the
> |> executor to alter the environment. All the exec's are execv's with explicit
> |> pathnames. What are the security holes involved with this?
>
> I wouldn't have thought the IFS environment variable should cause a
> problem providing that the things that you are execving are not Bourne
> Shell scripts (even then, as Peter Shipley says, it has been fixed
> in most versions of the Bourne Shell). Since the Bourne
> Shell has nothing to do with execv (unlike system, popen etc), the IFS
> env var will have no effect.
It really depends on what you are execving, and what does after that...
If you are execing something with privileges, you can no longer afford
to treat it like a "black box" that performs a task. It must be a
secured program as well.
> However, I agree with Peter that the LD_LIBRARY_PATH could be abused,
> but this is likely to be a general problem and not just one to do with
> programs that exec other programs.
In SunOS, the LD_* variables are ignored if the program is setid.
This has really annoyed me in the past, but I wouldn't have it any
other way. The problem occurs when a setid program calls a
non-setid program, and passes the LD_* variable down. The non-setid
program then interprets the LD_* variables, and faithfully loads your
trogan shared library or module. This is the case with the 'login',
'su', and 'sendmail' LD_* bugs.
rik.
--
Rik Harris - rik.harris@vifp.monash.edu.au || Systems Programmer
+61 3 560-3265 (AH) +61 3 565-3227 (BH) || and Administrator
Fac. of Computing & Info.Tech., Monash Uni, Australia || Vic. Institute of
http://www.vifp.monash.edu.au/people/rik.htm || Forensic Pathology